If I understand the original objection it's that passwords are stored
in cleartext on the postmaster machine. That's not much of an
objection since you have to have your secrets available in the clear
on both ends of a connection if you want the traffic on the
connection secured. Both the Solaris and NetBSD ppp implementations
have this characteristic. Kerberos IV encrypts the passwords on the
server, but the master password for that encryption is still stored
in "/.k" so it's the same in principle.
If I understand the current password implementation the postmaster
chooses the salt, sends it to the client which does a unix crypt and
returns the encrypted password for verification. This is a nice,
simple system which provides what I would consider a reasonable
minimum of security.
But it's not *really* secure. For one thing a bad guy could
intercept the encrypted password and feed it to one of the
password-guessing programs, like crack. It's not very robust to
man-in-the-middle attacks, either. Do we know how predictable the
salt-choosing algorithm is? What if a counterfeit server requested
authentication with a carefully-chosen salt (like 0)?
We are not in the business of creating security protocols. IMHO we
should leave that to the people who are. If we want something better
than the password scheme we have then we should adopt an existing
standard. Chap, as used with ppp, comes to mind. It might be a good
substitute for the password protocol.
Remember that we already support kerberos. Also there is no reason
you can't run the connection over an ssh tunnel. That solution would
protect the data as well as the passwords. There are applications
where the important information is not what's in the database, but
what information did someone want from it and when did they ask.
Out of curiosity does SecurityFocus.com also criticise pppd for the
same "problem"? The problem is not us storing the passwords in the
clear, but rather are we careful about the access permissions on the
file that contains them, and are we careful about how they get passed
around.
Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
